The concept of a configuration management database (CMDB) has been known for some time. According to a document known as the information technology infrastructure library (ITIL), a CMDB is defined as a database for managing an information technology (IT) system. Meanwhile, the ITIL is a guidebook proposed by British Commerce Department.
More particularly, in a CMDB is stored the information regarding configuration items (CIs) representing constituent elements of an IT system and the information regarding relationships between the CIs.
Explained below with reference to FIG. 27 is an example of a CMDB for managing the CIs constituting an IT system. FIG. 27 is an explanatory diagram for explaining a CMDB. As illustrated in FIG. 27, the CMDB stores therein CIs representing physical machines “PM: pm11” to “PM: pm13” and CIs representing virtual machines “VM: va01” to “VM: va03” and “VM: vb01” to “VM: vb03”. In addition, the CMDB stores therein CIs representing services “Svc: Ta” to “Svc: Tc” that are provided by the virtual machines. Besides, the CMDB also stores therein relationships from “01. vm-pm” to “20. vm-tenant” that represent the relationships between the abovementioned CIs.
For example, with reference to FIG. 27, the relationship “01. vm-pm” and the relationship “02. pm-vm” represent the relationships between the physical machine “PM: pm11” and the virtual machine “VM: va01”. Similarly, the relationship “13. vm-tenant” represents the relationship between the service “Svc: Ta” and the virtual machine “VM: va01”. Thus, in the CMDB illustrated in FIG. 27, it is specified that the virtual machine “VM: va01” is mounted on the physical machine “PM: pm11”, while the service “Svc: Ta” is provided by the virtual machine “VM: va01”.
In such a CMDB, if some relationships remain undefined, then an application that refers to the relationships may not be able to obtain proper results. Explained below is a case when, as an application referring to the relationships, an application that traces the CIs in which errors have occurred with the aim of uniquely identifying the CIs that have caused errors is not able to obtain proper results.
The case when the abovementioned application is unable to obtain proper results is explained with reference to FIG. 28. FIG. 28 is an explanatory diagram for explaining undefined relationships in the CMDB. In the example illustrated in FIG. 28, it is assumed that the occurrence of an error in the physical machine “PM: pm11” leads to the occurrence of an error in each of the virtual machine “VM: va01”, the virtual machine “VM: vb01”, the service “Svc: Ta”, the service “Svc: Tb”, and the service “Svc: Tc”. In addition, it is assumed that the relationship “03. pm-vm” and the relationship “04. vm-pm” representing the relationships between the physical machine “PM: pm11” and the virtual machine “VM: vb01” remain undefined. Meanwhile, in FIG. 28, each CI in which an error has occurred is flagged with a star sign.
Herein, for example, the application traces the relationship “16. vm-tenant” from the service “Svc: Tb” and identifies the virtual machine “VM: vb01” as the virtual machine providing the service “Svc: Tb”. Subsequently, the application attempts to trace relationships from the virtual machine “VM: vb01” and to identify the physical machine on which the virtual machine “VM: vb01” is mounted.
However, in the CMDB illustrated in FIG. 28, since the relationships “03. pm-vm” and “04. vm-pm” are not defined, the application is not able to trace the relationships “03. pm-vm” and “04. vm-pm” with the aim of identifying the physical machine on which the virtual machine “VM: vb01” is mounted. That is, the application is not able to identify the physical machine that has caused an error in the virtual machine “VM: vb01” and in the service “Svc: Tb”.
In this way, when an application is not able to properly trace the CIs stored in a CMDB, the user has to manually supplement the relationships in order to maintain the consistency of the CMDB. That is, in order to find out the undefined relationships, the user has to confirm whether all relationships that are supposed to be defined for each CI have actually been defined. If any relationship is found out to be undefined, then the user has to manually supplement that relationship (see, for example, Japanese Laid-open Patent Publication No. 2003-28935).
Thus, in the typical case when the user has to manually supplement the relationships; the user has to confirm whether all relationships that are supposed to be defined for each CI have actually been defined and, if any relationship is found out to be undefined, to manually supplement that relationship. Such a task requires a lot of time and efforts thereby making it difficult to supplement the undefined relationships.